1. Field of the Invention
The present invention relates to a method and system for reading out map data from a recording medium in which the map data are recorded, and supplying them to a navigation system.
2. Description of the Related Art
Heretofore, there has been a known navigation system which reads out map data recorded in a recording medium, such as a CD-ROM or a DVD, and displays the map data and the present location of a vehicle and also guides the vehicle by displaying an optimum route to a destination on the map data (Japanese Patent Laid-Open Publication No. Hei 2-129800).
It is considered that a recording medium to be used for such a navigation system should have sufficient compatibility so as not to rely on a hardware structure of the navigation system or an operating system (OS). In other words, it is desirable that different manufactures can provide recording media from area to area or various manufacturers having different sources of map data (for example, a data source of restaurants or a data source of hotels) can provide recording media.
As a method of securing compatibility of such a recording medium, there is a method of fixing a single recording format of the map data of the recording medium and previously letting a map data readout access program on the navigation system side have a very small procedure to read out desired map data.
However, such a method will not be realistic if the recent remarkable increase of navigation functions is taken into consideration, even if the map data necessary for the functions of the navigation system do not change for a long period of time (for example, ten years). More specifically, if the recording format is fixed, it will be impossible to cope with a future increase of the navigation functions. Thus, the navigation functions will be limited so as to maintain compatibility. Further, if a wide range of revision is required, it will be necessary to reconstruct the recording format.
Thus, in order to solve the problems mentioned above, a way (object oriented) to let the readout access program on the navigation side have an application programming interface (API) for reading out desired map data and let the recording medium have a method to read out the map data according to a message from the API together with the map data which are the pair to the method is proposed. In this way, when necessary navigation functions are added or revised, definition of the API is added or the API is revised. For each map data, a necessary recording format is then added or revised, and a necessary reading method which is paired with the map data is also added or revised. Thus, when a new API corresponding to a new function is outputted from the navigation system, the corresponding reading method reads out necessary map data, whereby the new function can be realized. Also, even when an old API is outputted from the navigation system only having old functions, it is possible to read out map data corresponding to the old API by the reading method, which is paired with the map data, according to the old API, thereby maintaining the compatibility. Of course, in this way, it is possible to meet the requirements of writing new data into the recording medium as well as reading.
However, there are various hardware (CPU or the like) and operating systems (OS) on the side of the navigation system. In addition, a reading method which is provided together with the map data in pairs relies on the CPU or the OS. Thus, it is generally difficult to unify the reading method so as to be applicable to all the hardware.
On the other hand, it is possible to unify the reading method by using, as a control program for realizing the navigation functions on the navigation system side, a program to be executed on a virtual machine like Java (trademark) which does not rely on specified hardware. However, a current hardware processing speed is accompanied with such a problem that readout access processing time of the map data increases. Especially, display of maps in the navigation system is performed when a driver of vehicle who is a user confirms a map changing its scale in a short time while driving or when a large-scale dedicated guide map of a crossing or a crossroads to be guided is displayed adjusting in a short time to timing of the guidance, and rapid readout is required. Thus, such an increase of map data readout time lowers the userfriendliness of the system.
Therefore, while employing C language or assembly language to constitute the processing program on the side of the navigation system in consideration of the processing speed of hardware, it is sought under the existing circumstances to use Java to constitute the control program on the navigation system side to take advantage of the recent remarkable progress of hardware processing speed. Consequently, it is likely that cases of using C language or assembly language to constitute the control program on the navigation system side and cases of using Java to constitute the program will be intermingled.
This means that program inconsistencies may arise. More specifically, even when a request for map data is issued from the navigation system side (control program for realizing the navigation functions) to a data access section (control program for reading out the map data requested by a map data storage section) to obtain desired map data, the C language constitutes the navigation system side, whereas the Java constitutes the data access section. Of course, it is generally been noted that an exchange of data between the object oriented C language (C++ or the like) and Java is realized by making the data object-oriented. However, a concrete processing method or system to cope with the inconsistency of control programs described above which may arise during the navigation in the case of data to be processed being the map data has not been developed.